Network monitoring and analysis systems are commonly utilized to ensure that networks are meeting particular Quality of Service (QoS) requirements, such as those associated with Internet Protocol (IP) telephony, also referred to as Voice over IP (VoIP). Such systems typically collect low-level network measurements, such as delay, jitter and packet loss. See, for example, U.S. Patent Application Publication No. 2005/0053009, entitled “Method and Apparatus for Automatic Determination of Performance Problem Locations in a Network,” which is commonly assigned herewith and incorporated by reference herein.
VoIP communications generally do not tolerate delay, jitter and packet loss well. Accordingly, the packets that make up such communications are usually given priority over the packets of other applications in the routing decisions made by routers and other network elements. This is typically achieved by marking the packets with a particular type of service (TOS) value. For example, a given byte of the TOS field in the IP header of a given VoIP packet may be marked at its source network element with a particular Differentiated Services Code Point (DSCP) value that is indicative of a VoIP packet. This may be, for example, a value of 46, or another designated value. All of the routers or other network elements involved in forwarding such packets are configured to expedite the delivery of packets that are marked in that way.
A significant problem arises when the routers or other network elements involved in forwarding VoIP packets inappropriately remark the TOS field of the IP header. Such remarking can interfere with IP telephony. To address this issue, network engineers often use so-called “sniffers” at source and destination network elements in order to determine whether the TOS field in the IP header of a given VoIP packet was changed during the trip from the source element to the destination element. Such sniffers may be able to detect that a change has been made in the TOS field somewhere within a given network path, but are unable to indicate the particular network element or elements that made the change. Also, if a remarked TOS value is subsequently returned to its original value by another network element on the path, the TOS value will appear based on the sniffers at the source and destination elements as if it was preserved end-to-end. Thus, it is possible that the sniffers will indicate no change in TOS value even though the TOS value may have been changed by several different network elements. The deficiencies of the sniffer approach are made worse by the fact that network paths can be very long and span a very large geographic area. Thus, the engineer is unable to easily locate the particular network element or elements that are performing the TOS remarking.
Similar deficiencies are present in those versions of conventional “traceroute” programs that provide an indication that a destination network element is unreachable for a particular TOS value. In this situation, the conventional traceroute program will generally give up and exit, again failing to provide any indication regarding the particular network element or elements that performed TOS remarking.